#+TITLE: Fantasy Vacation Planner Notes
#+AUTHOR: Zelphir Kaltstahl
#+STARTUP: content indent align inlineimages hideblocks entitiesplain nologdone nologreschedule nologredeadline nologrefile
#+TODO: TODO INPROGRESS | DONE
#+DATE: <2020-12-22 Di>
#+LANGUAGE: English
#+PRIORITIES: A E E

* Process

  1. count players
  2. find a vacation target
  3. find a means of travelling to get there
     - example:
       - taxi to airport
       - plane to other country
       - bus
  4. it is important when travelers leave their home
  5. travelers or the game master needs to write down delays or the program needs to keep track of them

* To do [2/14]

- [ ] Make all ~ask-user-...~ procedures take an additional keyword argument
  named ~input-port~, which defaults to ~(current-input-port)~ or use fluids /
  parameters.

- [ ] general descriptions / explanations of means of transportation, on the
  same level as the "event" attribute, simply to be displayed when that step of
  the journey starts

- [ ] ask for route change first, then ask for delay

- [-] add positive events
  - [X] get to know a person on the flight -> person gives you a ride to your hostel
  - [ ] find a wallet
  - [ ] find bottle of champagne
  - [ ] free smoke
  - [ ] find someone's phone and this person turns out to be your new crush, who will accompany you
  - [ ] an old acquaintance whom you meet on the flight invites you to eat English muffins
  - [ ] train arrives earlier
  - [ ] anything arrives earlier
  - [ ] arrive from international flight and a new queue is opened up for the customs service (luggage checking)
  - [ ] you are the n-th customer and get a free
    - [ ] upgrade to your hotel room
    - [ ] or flight class
    - [ ] train compartment class

- [ ] add neutral events
  - [ ] art sale during transport

- [ ] events for locations
  - [ ] on arrival at location process possible events
  - [ ] the manager of the hotel which you stay at really likes you
    - [ ] effect: no costs for the hotel
  - [ ] you get an upgrade for your room

- [ ] general events
  - [ ] pandemic
    - [ ] diarrhea
  - [ ] vulcano erruption
  - [ ] solar flares / solar winds
  - [ ] terrorists
  - [ ] "knallharter regen"
  - [ ] weather changes

- [ ] think about idea: delay or additional costs effect:
  - specify value
  - random centered around value
  - if no value specified ask player

- [ ] discomfort accounted for
  - [ ] nightmares
  - [ ] people smoking next to you
  - [ ] uncomfortable seat
  - [ ] did I lock my door?

- [ ] give log level to log procedures or make a macro

- [ ] Add more events:

  - hiking: bridge on map does not exist in reality (delay)
  - fall into a into stream when trying to jump over it (effect? -> slow -> delay?)
  - forgot meds (effect: need to head back -> delay?)
  - forgot food (effect? -> hungry -> slow -> delay?)

- [X] Perhaps let users choose the effects of the event by choosing an action they want to do when the event happens.

- [ ] add named command line arguments, to override config and set things like:
  - [ ] random seed
  - [ ] difficulty
  - [ ] min probability
  - [ ] max probability

** Feature: Karma

- [ ] neutral events that give positive and negative choices
  - [ ] pick up or not pick up person while riding the bike
    - [ ] positive or negative karma points

- [ ] karma points
  - [ ] calculation: (karma points * positive/negative multiplier specified by
    event) + prob. of event

- [ ] initial karma in general config (additional difficulty adjustment)

** Feature: Actions

- [ ] allow to always choose an action, even with empty action list, because
  there is always the choice of specifying a custom action

** Feature: General events

- [ ] add general events to the configuration and program, which can happen with
  any means of transportation

** Feature: Validation

- [ ] effects array can be enum members

** Feature: Summary [0/1]

- [ ] count number of events that happened to a player -> traveler state

* Design decisions

** Best design decisions

The best software design decisions are those, which help with development and maintenance of the software. Of the design decisions made in this project, the following seem to have been the most beneficial:

+ writing JSON schemata for validating JSON configuration files

  If there is a configuration related error, assuming, that the JSON respective
  schema is correct and as intended, this makes sure, that the mistake is not in
  the structure of a configuration file, but indeed in the program running with
  that configuration loaded. It takes one more thing off ones mind, making it
  reliable.

+ introducing the abstraction of an "event outcome"

  This greatly simplified dealing with events and event actions and simplified
  the code, which I was not quite satisfied with. Goes to show again: If one
  finds a good abstraction, one can make the code much more readable.

** Still unsure

+ splitting up the configuration files

  + positive aspects

    This seems to make it easier to update the separate configuration files, as
    mistakes can be found more easily, for example when the validation fails or
    when there is a simple syntax error.

    It enables me to quickly list all available means of transportation.

  + negative aspects

    It makes editing via search and replace or keyboard macros in Emacs take a
    bit more time.

  It might be a good trade-off.

+ using alists for handling the configuration even after loading the JSON files
  into the program

  On one hand the alists are very convenient to access using the extra functions
  I have implemented for that purpose, but on the other hand the code relies on
  data being alists and vectors in many places.

  Additional data abstraction procedures could be introduced to limit the
  required changes in case of configuration loading changes to the data
  abstraction layer, but would it be worth it in this case? How often, if ever,
  if the way configuration is loaded going to change? And why would alists not
  be a good choice for data, which is as small as the configuration of a program
  like this one?

  I could probably have used hash tables or something like that to store the
  configuration, but all that would achieve is swap the alist procedure calls
  with calls to hash table procedures.
